home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
201-225
/
disk_223
/
gravsim
/
readme
< prev
next >
Wrap
Text File
|
1992-05-06
|
6KB
|
182 lines
THE GRAVITY SIMULATOR: Page 1
A Gravity Simulator Animation Program
by
Richard Frost. (C) 1988
Compilation:
My program compiles under both Aztec 3.6a and 3.2a. The
program runs easily with 1/2 Meg and will load the sprite data
into chip ram and the rest of the program into FAST RAM (If you
are lucky enough to have any!!!).
This program is a real number cruncher and would BURN with
one of those 68020 and 68881 TURBO BOARDS!!
Bugs:
Not many, I am happy to say !. But there is this weird bug
that occurs if you are in the RECORD mode and you add a new
planet. Then, when you try to play the animation back... you
guessed it !, you get a visit from the friendly neighbourhood GURU
!
Basic Program Description:
My program can animate up to 6 planetary masses all of
which exert a mutual gravitational force on each other. The
planetary masses can be placed and removed from anywhere on the
screen and their mass and initial velocity can all be determined
by the user. The program then steps the animation through time, at
each stage plotting the new position in the trajectory for each
mass on the screen. The animation in this mode is obviously going
to be slow as the computer is calculating the paths in real time.
It is for this reason that I have used a large array storage
technique involving the use of a look-up table to record the
positions of the masses for each step in time. A record mode is
offered which allows the user at any time to record the animation
calculated in real time and then play it back at a variety of
speeds, this mode is useful as the complex interactions between
various masses can be more easily appreciated when the animation
is played back at full speed.
THE GRAVITY SIMULATOR: Page 2
Theory behind the animation:
To animate N bodies, each applying some gravitational force
on all the other bodies we must consider 1 mass at a time and for
that mass evaluate the total force vector applied to the mass due
to the gravitational force of attraction from all the remaining
masses. We then work out the the new acceleration of the mass from
Newton's First Law and hence it's new velocity and position. In
real life however, it things are not as simple as this. In my
model animation I have ignored possible quantum gravitional
effects such as the curvature of space-time and non constant
acceleration. My model behaves quite well under the assumption of
constant acceleration, this allows me to use the simple motion
equation: V2 = V1 + At, which increases speed of calculation, as
equations involving non constant acceleration would involve
possible Differential Equations and numerical methods, for 3
situations involving 3 or more masses. My assumption of constant
acceleration is not incorrect as long as I choose steps in time
which are relatively small when compared to the mutual force of
attraction between 2 given masses .
Some problems do arise when 2 masses get very close
together. In this situation the gravitational force is very large
(inversely proportional to the square of the separtation of the 2
masses) and consequently if I keep the same icrements in time as
when the masses are far apart, for the next frame the masses may
pass each other by and thus have the same velocity vector as
before the encounter took place. This results in both masses
heading off to infinity (leaving the screen very quickly) and
ending the animation. I partially solved this problem by refining
(reducing) my time increments appropriately (in fact I use a
linear reduction which depends on the separation of the 2 masses.)
this is seen in the section of C-code in the routine
GravityAttract which obtains the new X & Y velocities of a given
mass M1 due to the force applied by mass M2 :
If (r < 2000 )
{
TimeStep = r * 0.04 + 1;
}
else
TimeStep = 80.0;
where 'r' is the separation of the 2 masses. The number '0.04' was
arrived at after af few runs of the program and analysing how
close planets could get without unexpectantly leaving the screen.
This code part worked quite well and reduced the number of times
planets would fling off and leave the screen when they got too
close. This problem is always there and is inherent in its
algorithmic description, I know of no other simple technique that
comlpletely solves this problem.
Extra Notes:
THE GRAVITY SIMULATOR: Page 3
Because of my program's generality it is possible to set up
animations involving the animation of say, comet paths around a
star or very massive object and the familiar wobble motion a start
exhibits when it has planets orbiting it (Astronomers look for
this motion of a star to determine whether it has planets orbiting
around it. Also, due to the way I store the position values of
masses in the look-up table, masses are animated with various
speeds, this is due to the storing of multiple copies of the same
position of a given mass in the look-up table. I decided not to
store a position value and a count as my table uses more then one
object thus you cannot have situations where large consecutive
portions of the array contain the same postion values.